fix(codegen): test nested constructor patterns — three backends emitted the same guard - #732

…ed the same guard

Fixes #731.

A match whose arms differed only in a NESTED constructor emitted identical
guards, so every arm after the first was unreachable and the first arm's body
ran for all of them. It type-checked; only the emitted code was wrong.

    | PatCon (id, _) -> scrut ^ ".tag === " ^ ...
                  ^
                  the sub-patterns, discarded

WIDER THAN THE ISSUE SAID. I filed #731 against the Deno-ESM backend. It is in
THREE:

    lib/codegen_deno.ml:1222   Deno-ESM
    lib/js_codegen.ml:379      plain JS
    lib/lua_codegen.ml:102     Lua

Each has its own gen_pattern_test with the same defect. Checked the rest:
c_codegen, codegen_gc, wasm_backend and native_backend do not share this
lowering path.

WHY IT STAYED INVISIBLE. gen_pattern_bindings in every one of the three was
ALREADY descending correctly, binding through .value / .values[i]. So the
bound variables landed on the right values and the output looked entirely
plausible -- it just took the wrong branch. Only the TEST was truncated to the
outermost constructor.

    before:  if (__scrut.tag === "Some")
             if (__scrut.tag === "Some")            <- identical
    after:   if (__scrut.tag === "Some" && __scrut.value.tag === "Circle")
             if (__scrut.tag === "Some" && __scrut.value.tag === "Square")

VERIFIED BY EXECUTION, not by reading the output:

    Circle(1) -> 1      (expect 1)      was 1
    Square(1) -> 1001   (expect 1001)   was 1

The fix mirrors gen_pattern_bindings exactly in each backend -- .value for
arity 1, .values[i] otherwise -- so test and binding paths cannot drift apart.
Sub-patterns that test "true" (a variable or wildcard) are dropped from the
conjunction, so guards read "tag === X && value.tag === Y" rather than
trailing a string of "&& true".

WHY THIS MATTERED NOW. Found while hand-porting the first complete .affine file
in metadatastician/stapeln, where a JFloat id returned Ok(2.7) from a function
declared -> Result<Int, String>: a Float escaping into an Int position, i.e.
the emitted program violating the signature the checker had accepted.

Nested patterns are not an edge case -- they are the ordinary shape of
decoders, of Option/Result over a sum type, and of every TEA update function.
The ReScript -> AffineScript campaign covers ~3,996 files across ~80 repos, and
until this landed any ported file using them could pass check, pass review, and
run wrong.

Self-merged under the owner's standing --admin grant.

The 534-test suite had a nested-TUPLE pattern test but none for nested
CONSTRUCTORS on the JS-family backends, which is why #731 survived. This
adds one for the Deno-ESM and plain-JS paths.

Verified to be a real guard, not decoration: reverting the PatCon arm in
codegen_deno.ml turns exactly this test red (1 failure, named), and
restoring it returns the suite to green.

The assertion is that the inner constructor appears in a GUARD. Asserting
on bindings would prove nothing -- gen_pattern_bindings was already
descending correctly, and that asymmetry is precisely what hid the bug.